Test Code
テストの分類とか
とはいえ、Testの分類が不明瞭なので、ここをギチギチにやる意味はあまりないと思っているmrsekut.icon 最近のfrontendでの分類
最近のbackendでの分類
名前が付いてるやつ
実行結果の安定しないテスト
開発手法とか
テストの仕方とか
異常系？
正常系？
全パターン網羅する？
対象ごとに
下の方は厳密に、上の方はゆるく
出来るだけ落ちやすいテストケース
落とす目的でも良さそう（？）
テストコード、正常系から書くか、異常系から書くか
テストコードを書く意義、書くことで得られる恩恵
テスト全般の知識
テストの分類、テストコードの分類
テストコードの書き方
個別具体的なテストコードの書き方
言語、テストライブラリ、フレームワーク
テスト項目の作り方
手動テストの心構え
「テスト」と言っても、いろいろな分類ができる
テストレベルで区切る
単体、結合、..
手動 v.s. 自動で区切る
誰のためにテストするか
開発者、ユーザー、..
なぜテストをするか
利用者に意図を伝える(test as documentation)
テストをメンテする人にとっても理解しやすくメンテしやすいものでないといけない
小さく、読みやすく、そのテストの意図も明確
テストがないと利用者はその対象の挙動を理解して利用するために以下のような手順を踏む必要が出てくる ref コードを読んで動作を理解する
ドキュメントを読む
実際に動かして試してみる
作成者に聞く
誰のためのテスト？
開発者のため？
顧客のため？
組合せ爆発するテスト要件を、どう表現するか
今やりたいのは実機テストのための表ではあるが、これはテストコードのときも似たような話になりそう
なので、エクセルみたいな2次元の表に、どうやって5次元の内容を書くか、みたいんところが気になっている
簡単な例では
ユーザーの種類
ゲスト
emailで登録したユーザー
phoneで登録したユーザー
両方で登録したユーザー
ユーザーの経路
Aができる
Bができる
Cができる
モバイルのOS(やVersion)
Android
iPhone
iPad
これだけで3*3パターンのテスト項目ができる
エクセルのような二次元の表に記述しづらい
OK/NGの結果などを残しづらい
表現するのもそうだが、実施するかどうかの話もある
選択肢が多すぎるものを全部行うのは非現実的
バグが起こりやすそうなところ、を精査して実施するなど
参考
テストの短所
リリースのたびに同じ箇所のテストを繰り返す必要がある
↓この辺をまとめる
バグ報告されてそれを改修するときに、そこに正しく型付けがされていたのかどうかを細かくチェックするといいmrsekut.icon 自動テスト
アド彼
7原則
ベスプラ